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Abstract 


This document defines a set of RADIUS attributes designed to support 
the provision of compulsory tunneling in dial-up networks. 


1. Motivation 


Many applications of tunneling protocols such as L2TP involve dial-up 
network access. Some, such as the provision of access to corporate 
intranets via the Internet, are characterized by voluntary tunneling: 
the tunnel is created at the request of the user for a specific 
purpose. Other applications involve compulsory tunneling: the tunnel 
is created without any action from the user and without allowing the 
user any choice in the matter. In order to provide this 
functionality, new RADIUS attributes are needed to carry the 
tunneling information from the RADIUS server to the tunnel end 
points; this document defines those attributes. Specific 
recommendations for, and examples of, the application of these 
attributes for L2TP can be found in RFC 2809. 
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3.5 


Specification of Requirements 


In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 
described in [14]. 


Attributes 


Multiple instances of each of the attributes defined below may be 
included in a single RADIUS packet. In this case, the attributes to 
be applied to any given tunnel SHOULD all contain the same value in 
their respective Tag fields; otherwise, the Tag field SHOULD NOT be 
used. 


If the RADIUS server returns attributes describing multiple tunnels 
then the tunnels SHOULD be interpreted by the tunnel initiator as 
alternatives and the server SHOULD include an instance of the 
Tunnel-Preference Attribute in the set of Attributes pertaining to 
each alternative tunnel. Similarly, if the RADIUS client includes 
multiple sets of tunnel Attributes in an Access-Request packet, all 
the Attributes pertaining to a given tunnel SHOULD contain the same 
value in their respective Tag fields and each set SHOULD include an 
appropriately valued instance of the Tunnel-Preference Attribute. 


1. Tunnel-Type 
Description 


This Attribute indicates the tunneling protocol(s) to be used (in 
the case of a tunnel initiator) or the the tunneling protocol in 
use (in the case of a tunnel terminator). It MAY be included in 
Access-Request, Access-Accept and Accounting-Request packets. If 
the Tunnel-Type Attribute is present in an Access-—Request packet 
sent from a tunnel initiator, it SHOULD be taken as a hint to the 
RADIUS server as to the tunnelling protocols supported by the 
tunnel end-point; the RADIUS server MAY ignore the hint, however. 
A tunnel initiator is not required to implement any of these 
tunnel types; if a tunnel initiator receives an Access-—Accept 
packet which contains only unknown or unsupported Tunnel-Types, 
the tunnel initiator MUST behave as though an Access-Reject had 
been received instead. 


If the Tunnel-Type Attribute is present in an Access—Request 
packet sent from a tunnel terminator, it SHOULD be taken to 
signify the tunnelling protocol in use. In this case, if the 
RADIUS server determines that the use of the communicated protocol 
is not authorized, it MAY return an Access-Reject packet. If a 
tunnel terminator receives an Access-Accept packet which contains 
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one or more Tunnel-Type Attributes, none of which represent the 
tunneling protocol in use, the tunnel terminator SHOULD behave as 
though an Access-Reject had been received instead. 


A summary of the Tunnel-Type Attribute format is shown below. The 
fields are transmitted from left to right. 


0 1 2: 3 
OMe 22s E. ES Ge 8 OOF De 23) A 516. TF 88: 9 Ot Ne Pe SA Bs Oe B89" Or A 
+—t-+-+-4+-4+-4+-4+-4+-4+-4+-+-+-4-4-4+-4-4-4-4-4-4-4-4-4-t-t-t-t-t-t-4-4 

| Type | Length | Tag | Value 

+—t-t+-+-4+-4+-4+-4+-4+-4+-4+-+-+-4-4-4-4+-4-4-4-4-4-4-4-4-t-t-t-t-t-t-4-4 
Value (cont) | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type 
64 for Tunnel-Type 


Length 
Always 6. 


Tag 
The Tag field is one octet in length and is intended to provide a 
means of grouping attributes in the same packet which refer to the 
same tunnel. Valid values for this field are 0x01 through 0x1F, 
inclusive. If the Tag field is unused, it MUST be zero (0x00). 


Value 
The Value field is three octets and contains one of the following 
values, indicating the type of tunnel to be started. 


sl Point-to-Point Tunneling Protocol (PPTP) [1] 

2 Layer Two Forwarding (L2F) [2] 

3 Layer Two Tunneling Protocol (L2TP) [3] 

4 Ascend Tunnel Management Protocol (ATMP) [4] 

5 Virtual Tunneling Protocol (VTP) 

6 IP Authentication Header in the Tunnel-mode (AH) [5] 
7 TP-in-IP Encapsulation (IP-IP) [6] 

8 Minimal IP-in-IP Encapsulation (MIN-IP-IP) [7] 

9 IP Encapsulating Security Payload in the Tunnel-mode (ESP) [8] 
10 Generic Route Encapsulation (GRE) [9] 

11 Bay Dial Virtual Services (DVS) 

12 IP-in-IP Tunneling [10] 
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3.2. Tunnel-—Medium-Type 
Description 


The Tunnel-Medium-Type Attribute indicates which transport medium 
to use when creating a tunnel for those protocols (such as L2TP) 
that can operate over multiple transports. It MAY be included in 
both Access-—Request and Access-Accept packets; if it is present in 
an Access-—Request packet, it SHOULD be taken as a hint to the 
RADIUS server as to the tunnel media supported by the tunnel end- 
point. The RADIUS server MAY ignore the hint, however. 


A summary of the Tunnel-Medium-Type Attribute format is given below. 
The fields are transmitted left to right. 


0 d 2 3 
OIZ 3456 7 8g 9 012.34 5 678.9 0 L2 3A 6 7 8 9-0-1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Length | Tag | Value 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Value (cont) 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type 
65 for Tunnel-Medium-Type 


Length 
6 


Tag 
The Tag field is one octet in length and is intended to provide a 
means of grouping attributes in the same packet which refer to the 
same tunnel. Valid values for this field are 0x01 through 0x1F, 
inclusive. If the Tag field is unused, it MUST be zero (0x00). 


Value 
The Value field is three octets and contains one of the values 
listed under "Address Family Numbers" in [14]. For the sake of 


convenience, a relevant excerpt of this list is reproduced below. 


802 (includes all 802 media plus Ethernet "canonical format") 
E.163 (POTS) 
E.164 (SMDS, Frame Relay, ATM) 


ali IPv4 (IP version 4) 

2 IPv6 (IP version 6) 

3 NSAP 

4 HDLC (8-bit multidrop) 
5 BBN 1822 

6 

7 

8 


Zorn, et al. Informational [Page 4] 


RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 


9 F.69 (Telex) 

10 X.121 (X.25, Frame Relay) 

1 IPX 

12 Appletalk 

13 Decnet IV 

14 Banyan Vines 

15 E.164 with NSAP format subaddress 
3.3. Tunnel-Client-Endpoint 

Description 


This Attribute contains the address of the initiator end of the 
tunnel. It MAY be included in both Access-Request and Access- 
Accept packets to indicate the address from which a new tunnel is 
to be initiated. If the Tunnel-Client-Endpoint Attribute is 
included in an Access-Request packet, the RADIUS server should 
take the value as a hint; the server is not obligated to honor the 
hint, however. This Attribute SHOULD be included in Accounting- 
Request packets which contain Acct-Status-Type attributes with 
values of either Start or Stop, in which case it indicates the 
address from which the tunnel was initiated. This Attribute, 
along with the Tunnel-Server-Endpoint and Acct-Tunnel-Connection- 
ID attributes, may be used to provide a globally unique means to 
identify a tunnel for accounting and auditing purposes. 


A summary of the Tunnel-Client-Endpoint Attribute format is shown 
below. The fields are transmitted from left to right. 


0 
0 


J: 2 3 
Le 2 SAD e PS. OY Or I 23 A S62 FB: Oe ON L 2 3 A G FP 8 90 L 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type | Length | Tag | String 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type 


66 for Tunnel-Client-Endpoint. 


Length 


Zorn, 


>= 3 
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Tag 


The Tag field is one octet in length and is intended to provide a 
means of grouping attributes in the same packet which refer to the 
same tunnel. If the value of the Tag field is greater than 0x00 
and less than or equal to Ox1F, it SHOULD be interpreted as 
indicating which tunnel (of several alternatives) this attribute 
pertains. If the Tag field is greater than 0x1F, it SHOULD be 
interpreted as the first byte of the following String field. 


String 


The format of the address represented by the String field depends 
upon the value of the Tunnel-—Medium-Type attribute. 


If Tunnel-Medium-Type is IPv4 (1), then this string is either the 
fully qualified domain name (FQDN) of the tunnel client machine, 
or it is a "dotted-decimal" IP address. Conformant 
implementations MUST support the dotted-decimal format and SHOULD 
support the FQDN format for IP addresses. 


If Tunnel-Medium-Type is IPv6 (2), then this string is either the 
FQDN of the tunnel client machine, or it is a text representation 
of the address in either the preferred or alternate form [17]. 
Conformant implementations MUST support the preferred form and 
SHOULD support both the alternate text form and the FQDN format 
for IPv6 addresses. 


If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a 
tag referring to configuration data local to the RADIUS client 
that describes the interface and medium-specific address to use. 


Tunnel-Server-Endpoint 


Description 


Zorn, 


This Attribute indicates the address of the server end of the 
tunnel. The Tunnel-Server-Endpoint Attribute MAY be included (as 
a hint to the RADIUS server) in the Access-—Request packet and MUST 
be included in the Access-Accept packet if the initiation of a 
tunnel is desired. It SHOULD be included in Accounting-Request 
packets which contain Acct-Status-Type attributes with values of 
either Start or Stop and which pertain to a tunneled session. 
This Attribute, along with the Tunnel-Client-Endpoint and Acct- 
Tunnel-Connection-ID Attributes [11], may be used to provide a 
globally unique means to identify a tunnel for accounting and 
auditing purposes. 
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A summary of the Tunnel-Server-Endpoint Attribute format is shown 
below. The fields are transmitted from left to right. 


0 1 2 3 

(O 2.3. 425-20" 28 69S OE EE S At 5. 62°F E a O sd 2) 3. O Or he. O 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | Tag | String 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type 
67 for Tunnel-Server-Endpoint. 


Length 
>= 3 


Tag 
The Tag field is one octet in length and is intended to provide a 
means of grouping attributes in the same packet which refer to the 
same tunnel. If the value of the Tag field is greater than 0x00 
and less than or equal to 0x1F, it SHOULD be interpreted as 
indicating which tunnel (of several alternatives) this attribute 
pertains. If the Tag field is greater than 0x1F, it SHOULD be 
interpreted as the first byte of the following String field. 


String 
The format of the address represented by the String field depends 
upon the value of the Tunnel-Medium-Type attribute. 


If Tunnel-Medium-Type is IPv4 (1), then this string is either the 
fully qualified domain name (FQDN) of the tunnel client machine, 
or it is a "dotted-decimal" IP address. Conformant 
implementations MUST support the dotted-decimal format and SHOULD 
support the FQDN format for IP addresses. 


If Tunnel-Medium-Type is IPv6 (2), then this string is either the 
FQDN of the tunnel client machine, or it is a text representation 
of the address in either the preferred or alternate form [17]. 
Conformant implementations MUST support the preferred form and 
SHOULD support both the alternate text form and the FQDN format 
for IPv6 addresses. 


If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag 


referring to configuration data local to the RADIUS client that 
describes the interface and medium-specific address to use. 
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3.5. Tunnel-Password 
Description 


This Attribute may contain a password to be used to authenticate 
to a remote server. It may only be included in an Access-Accept 
packet. 


A summary of the Tunnel-Password Attribute format is shown below. 
The fields are transmitted from left to right. 


0 f 2 3 
Oo 2-349. S E E e e e O 2) 34 E E 8 OO 2 3 49 467 8 Od 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Type | Length | Tag | Salt 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Salt (cont) | String 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type 
69 for Tunnel-Password 


Length 
>= 5 


Tag 
The Tag field is one octet in length and is intended to provide a 
means of grouping attributes in the same packet which refer to the 
same tunnel. Valid values for this field are 0x01 through 0x1F, 
inclusive. If the value of the Tag field is greater than 0x00 and 
less than or equal to 0x1F, it SHOULD be interpreted as indicating 
which tunnel (of several alternatives) this attribute pertains; 
otherwise, the Tag field SHOULD be ignored. 


Salt 
The Salt field is two octets in length and is used to ensure the 
uniqueness of the encryption key used to encrypt each instance of 
the Tunnel-Password attribute occurring in a given Access-Accept 
packet. The most significant bit (leftmost) of the Salt field 
MUST be set (1). The contents of each Salt field in a given 
Access-Accept packet MUST be unique. 


String 
The plaintext String field consists of three logical sub-fields: 
the Data-Length and Password sub-fields (both of which are 
required), and the optional Padding sub-field. The Data-Length 
sub-field is one octet in length and contains the length of the 
unencrypted Password sub-field. The Password sub-field contains 
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3.56% 


the actual tunnel password. If the combined length (in octets) of 
the unencrypted Data-Length and Password sub-fields is not an even 
multiple of 16, then the Padding sub-field MUST be present. If it 
is present, the length of the Padding sub-field is variable, 
between 1 and 15 octets. The String field MUST be encrypted as 
follows, prior to transmission: 


Construct a plaintext version of the String field by 
concatenating the Data-Length and Password sub-fields. If 
necessary, pad the resulting string until its length (in 
octets) is an even multiple of 16. It is recommended that zero 
octets (0x00) be used for padding. Call this plaintext P. 


Call the shared secret S, the pseudo-random 128-bit Request 
Authenticator (from the corresponding Access-—Request packet) R, 
and the contents of the Salt field A. Break P into 16 octet 


chunks p(1), p(2)...p(i), where i = len(P)/16. Call the 
ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C. 
Intermediate values b(1), b(2)...c(i) are required. Encryption 
is performed in the following manner (’+’ indicates 
concatenation): 
b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1) 
b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C=C + c(2) 
b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C=C + c(i) 


The resulting encrypted String field will contain 
c(1)t+e(2)+...4+c(1i). 


On receipt, the process is reversed to yield the plaintext String. 


Tunnel-Private-Group-ID 


Description 


Zorn, 


This Attribute indicates the group ID for a particular tunneled 
session. The Tunnel-Private-Group-ID Attribute MAY be included in 
the Access-Request packet if the tunnel initiator can pre- 
determine the group resulting from a particular connection and 
SHOULD be included in the Access-Accept packet if this tunnel 
session is to be treated as belonging to a particular private 
group. Private groups may be used to associate a tunneled session 
with a particular group of users. For example, it may be used to 
facilitate routing of unregistered IP addresses through a 
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particular interface. It SHOULD be included in Accounting-—Request 
packets which contain Acct-Status-Type attributes with values of 
either Start or Stop and which pertain to a tunneled session. 


A summary of the Tunnel-Private-Group-ID Attribute format is shown 
below. The fields are transmitted from left to right. 


0 1 2 3 

O S E Or P28 O E 2203) A562 e a O S a Se 6°28 9" OO 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | Tag | String 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type 
81 for Tunnel-Private-Group-ID. 


Length 
>= 3 


Tag 
The Tag field is one octet in length and is intended to provide a 
means of grouping attributes in the same packet which refer to the 
same tunnel. If the value of the Tag field is greater than 0x00 
and less than or equal to 0x1F, it SHOULD be interpreted as 
indicating which tunnel (of several alternatives) this attribute 
pertains. If the Tag field is greater than 0x1F, it SHOULD be 
interpreted as the first byte of the following String field. 


String 
This field must be present. The group is represented by the 
String field. There is no restriction on the format of group IDs. 


3.7. Tunnel-Assignment-ID 
Description 


This Attribute is used to indicate to the tunnel initiator the 
particular tunnel to which a session is to be assigned. Some 
tunneling protocols, such as PPTP and L2TP, allow for sessions 
between the same two tunnel endpoints to be multiplexed over the 
same tunnel and also for a given session to utilize its own 
dedicated tunnel. This attribute provides a mechanism for RADIUS 
to be used to inform the tunnel initiator (e.g. PAC, LAC) whether 
to assign the session to a multiplexed tunnel or to a separate 
tunnel. Furthermore, it allows for sessions sharing multiplexed 
tunnels to be assigned to different multiplexed tunnels. 
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Zorn, 


A particular tunneling implementation may assign differing 


characteristics to particular tunnels. For example, different 
tunnels may be assigned different QOS parameters. Such tunnels 
may be used to carry either individual or multiple sessions. The 


Tunnel-Assignment-ID attribute thus allows the RADIUS server to 
indicate that a particular session is to be assigned to a tunnel 
that provides an appropriate level of service. It is expected 
that any QOS-related RADIUS tunneling attributes defined in the 
future that accompany this attribute will be associated by the 
tunnel initiator with the ID given by this attribute. In the 
meantime, any semantic given to a particular ID string is a matter 
left to local configuration in the tunnel initiator. 


The Tunnel-Assignment-ID attribute is of significance only to 
RADIUS and the tunnel initiator. The ID it specifies is intended 
to be of only local use to RADIUS and the tunnel initiator. The 
ID assigned by the tunnel initiator is not conveyed to the tunnel 
peer. 


This attribute MAY be included in the Access-Accept. The tunnel 
initiator receiving this attribute MAY choose to ignore it and 
assign the session to an arbitrary multiplexed or non-multiplexed 
tunnel between the desired endpoints. This attribute SHOULD also 
be included in Accounting-Request packets which contain Acct- 
Status-Type attributes with values of either Start or Stop and 
which pertain to a tunneled session. 


If a tunnel initiator supports the Tunnel-Assignment-ID Attribute, 
then it should assign a session to a tunnel in the following 
manner: 


If this attribute is present and a tunnel exists between the 
specified endpoints with the specified ID, then the session 
should be assigned to that tunnel. 


If this attribute is present and no tunnel exists between the 
specified endpoints with the specified ID, then a new tunnel 
should be established for the session and the specified ID 
should be associated with the new tunnel. 


If this attribute is not present, then the session is assigned 
to an unnamed tunnel. If an unnamed tunnel does not yet exist 
between the specified endpoints then it is established and used 
for this and subsequent sessions established without the 
Tunnel-Assignment-ID attribute. A tunnel initiator MUST NOT 
assign a session for which a Tunnel-Assignment-ID Attribute was 
not specified to a named tunnel (i.e. one that was initiated by 
a session specifying this attribute). 
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+-+ 
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Len 


Tag 


Str 


3:8: 


Des 
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Note that the same ID may be used to name different tunnels if 
such tunnels are between different endpoints. 


ummary of the Tunnel-Assignment-ID Attribute format is shown 
ow. The fields are transmitted from left to right. 


Í 2 3 
L2 3A eo F-89023) 4 6. eB 90> Te 2:93. 4 25) -6 “7-8. 9.0) 1 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Type | Length | Tag | String 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


e 
82 for Tunnel-Assignment-ID. 


gth 
>= 3 


The Tag field is one octet in length and is intended to provide a 
means of grouping attributes in the same packet which refer to the 
same tunnel. If the value of the Tag field is greater than 0x00 
and less than or equal to 0x1F, it SHOULD be interpreted as 
indicating which tunnel (of several alternatives) this attribute 
pertains. If the Tag field is greater than 0x1F, it SHOULD be 
interpreted as the first byte of the following String field. 


ing 
This field must be present. The tunnel ID is represented by the 
String field. There is no restriction on the format of the ID. 


Tunnel-Preference 
cription 


If more than one set of tunneling attributes is returned by the 
RADIUS server to the tunnel initiator, this Attribute SHOULD be 
included in each set to indicate the relative preference assigned 
to each tunnel. For example, suppose that Attributes describing 
two tunnels are returned by the server, one with a Tunnel-Type of 
PPTP and the other with a Tunnel-Type of L2TP. If the tunnel 
initiator supports only one of the Tunnel-Types returned, it will 
initiate a tunnel of that type. If, however, it supports both 
tunnel protocols, it SHOULD use the value of the Tunnel-Preference 
Attribute to decide which tunnel should be started. The tunnel 
having the numerically lowest value in the Value field of this 
Attribute SHOULD be given the highest preference. The values 
assigned to two or more instances of the Tunnel-Preference 
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Attribute within a given Access-Accept packet MAY be identical. 

In this case, the tunnel initiator SHOULD use locally configured 
metrics to decide which set of attributes to use. This Attribute 
MAY be included (as a hint to the server) in Access—Request 
packets, but the RADIUS server is not required to honor this hint. 


A summary of the Tunnel-Preference Attribute format is shown below. 
The fields are transmitted from left to right. 


0 


al 2 3 


OO! 23) 4 Or 6 BAO Od 2S 4 S67 8 GO 2-3 Al 162 89> OSL 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type | Length | Tag | Value 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Value (cont) 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type 


83 for Tunnel-Preference 


Length 


Always 6. 


Tag 


The Tag field is one octet in length and is intended to provide a 
means of grouping attributes in the same packet which refer to the 
same tunnel. Valid values for this field are 0x01 through 0x1F, 
inclusive. If the Tag field is unused, it MUST be zero (0x00). 


Value 


The Value field is three octets in length and indicates the 
preference to be given to the tunnel to which it refers; higher 
preference is given to lower values, with 0x000000 being most 
preferred and OxFFFFFF least preferred. 


Tunnel-Client-—Auth-ID 


Description 


Zorn, 


This Attribute specifies the name used by the tunnel initiator 
during the authentication phase of tunnel establishment. The 
Tunnel-Client-Auth-ID Attribute MAY be included (as a hint to the 
RADIUS server) in the Access-—Request packet, and MUST be included 
in the Access-Accept packet if an authentication name other than 
the default is desired. This Attribute SHOULD be included in 
Accounting-Request packets which contain Acct-Status-Type 
attributes with values of either Start or Stop and which pertain 
to a tunneled session. 
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A summary of the Tunnel-Client-Auth-ID Attribute format is shown 
below. The fields are transmitted from left to right. 


0 1 2 3 

(O A 2 S405: ES E aa a Oe e213) At 5. 62°78 OF O 2) 3. AN Or he 8. O 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | Tag | String 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type 
90 for Tunnel-Client-Auth-ID. 


Length 
>= 3 


Tag 
The Tag field is one octet in length and is intended to provide a 
means of grouping attributes in the same packet which refer to the 
same tunnel. If the value of the Tag field is greater than 0x00 
and less than or equal to 0x1F, it SHOULD be interpreted as 
indicating which tunnel (of several alternatives) this attribute 
pertains. If the Tag field is greater than 0x1F, it SHOULD be 
interpreted as the first byte of the following String field. 


String 
This field must be present. The String field contains the 
authentication name of the tunnel initiator. The authentication 
name SHOULD be represented in the UTF-8 charset. 


3.10. Tunnel-Server-Auth-ID 
Description 


This Attribute specifies the name used by the tunnel terminator 
during the authentication phase of tunnel establishment. The 
Tunnel-Client-Auth-ID Attribute MAY be included (as a hint to the 
RADIUS server) in the Access-Request packet, and MUST be included 
in the Access-Accept packet if an authentication name other than 
the default is desired. This Attribute SHOULD be included in 
Accounting-Request packets which contain Acct-Status-Type 
attributes with values of either Start or Stop and which pertain 
to a tunneled session. 


A summary of the Tunnel-Server-Auth-ID Attribute format is shown 
below. The fields are transmitted from left to right. 
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0 1 2 3 
On, 235 4.546 7 8D O81. 2° 3 4B 6 8S O12 3 4S S 8 OO 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Length | Tag | String 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type 
91 for Tunnel-Server-Auth-ID. 


Length 
>= 3 


Tag 
The Tag field is one octet in length and is intended to provide a 
means of grouping attributes in the same packet which refer to the 
same tunnel. If the value of the Tag field is greater than 0x00 
and less than or equal to 0x1F, it SHOULD be interpreted as 
indicating which tunnel (of several alternatives) this attribute 
pertains. If the Tag field is greater than 0x1F, it SHOULD be 
interpreted as the first byte of the following String field. 


String 
This field must be present. The String field contains the 
authentication name of the tunnel terminator. The authentication 
name SHOULD be represented in the UTF-8 charset. 


4. Table of Attributes 


The following table provides a guide to which of the above attributes 
may be found in which kinds of packets, and in what quantity. 


Request Accept Reject Challenge Acct-Request # Attribute 
O+ O+ 0 0 0-1 64 Tunnel-Type 


O+ O+ 0 0 0-1 65 Tunnel-Medium-Type 

O+ O+ 0 0 0-1 66 Tunnel-Client-—Endpoint 
O+ O+ 0 0 0-1 67 Tunnel-Server-Endpoint 
0 O+ 0 0 0 69 Tunnel-Password 

O+ O+ 0 0 0-1 81 Tunnel-Private-Group-ID 
0 O+ 0 0 0-1 82 Tunnel-Assignment-ID 

O+ O+ 0 0 0 83 Tunnel-Preference 

O+ O+ 0 0 0-1 90 Tunnel-Client-—Auth-ID 
O+ O+ 0 0 0-1 91 Tunnel-Server-Auth-ID 


The following table defines the meaning of the above table entries. 


0 This attribute MUST NOT be present in packet. 
O+ Zero or more instances of this attribute MAY be present in packet. 
0-1 Zero or one instance of this attribute MAY be present in packet. 
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5. Security Considerations 


The Tunnel-Password Attribute may contain information which should 


only be known to a tunnel endpoint. However, the method used to hide 
the value of the attribute is such that intervening RADIUS proxies 
will have knowledge of the contents. For this reason, the Tunnel- 


Password Attribute SHOULD NOT be included in Access-Accept packets 
which may pass through (relatively) untrusted RADIUS proxies. In 
addition, the Tunnel-Password Attribute SHOULD NOT be returned to an 
unauthenticated client; if the corresponding Access-Request packet 
did not contain a verified instance of the Signature Attribute [15], 
the Access-Accept packet SHOULD NOT contain an instance of the 
Tunnel-Password Attribute. 


Tunnel protocols offer various levels of security, from none (e.g., 
PPTP) to strong (e.g., IPSec). Note, however, that in the compulsory 
tunneling case any security measures in place only apply to traffic 
between the tunnel endpoints. In particular, end-users SHOULD NOT 
rely upon the security of the tunnel to protect their data; 
encryption and/or integrity protection of tunneled traffic MUST NOT 
be considered as a replacement for end-to-end security. 


6. IANA Considerations 


This document defines a number of "magic" numbers to be maintained by 
the IANA. This section explains the criteria to be used by the IANA 
to assign additional numbers in each of these lists. The following 
subsections describe the assignment policy for the namespaces defined 
elsewhere in this document. 


6.1. Tunnel-Type Attribute Values 
Values 1-12 of the Tunnel-Type Attribute are defined in Section 5.1; 
the remaining values are available for assignment by the IANA with 
IETF Consensus [16]. 

6.2. Tunnel-Medium-Type Attribute Values 
Values 1-15 of the Tunnel-Medium-Type Attribute are defined in 
Section 5.2; the remaining values are available for assignment by the 
IANA with IETF Consensus [16]. 
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This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
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developing Internet standards in which case the procedures for 
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